View AMD-8131_1316757.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

preliminary information AMD-8131 tm hypertransport tm pci-x tunnel revision guide publication # 26310 rev: 3.02 issue date: july 2003
preliminary information trademarks amd, the amd arrow logo, and combinat ions thereof, and AMD-8131 are trademar ks of advanced micro devices, inc. hypertransport is a licensed trademark of the hypertransport technology consortium. other product names used in this publication are for identifica tion purposes only and may be trad emarks of their respective com panies. ? 2003 advanced micro devices, inc. all rights reserved. the contents of this document are provided in connection with advanced micro devices, inc. (?amd?) products. amd ma kes no representations or warranties with re spect to the accuracy or completeness of the contents of this publicat ion and reserves the ri ght to make changes to specifications and product descri ptions at any time without notic e. no license, whether express, implied, arising by estoppel or ot herwise, to any inte llectual property right s is granted by this publication. except as set forth in amd?s standard terms and c onditions of sale, amd assumes no liability whatsoever , and disclaims any express or implied warranty, relating to its products including, but not limited to, the impl ied warranty of merchantab ility, fitness for a par- ticular purpose, or infringement of any intellectual property right. the amd products described here in may contain defects or a nomalies that cause the amd products to deviate from published specifications. amd?s products are not designed, intended, authorized or warranted for use as components in systems intended for surgical implant into the body , or in other applications intended to support or sustain life, or in any other application in which the failure of amd?s product could create a situation where personal injury, death, or severe property or environmental damage may occur. amd reserves the right to disc ontinue or make changes to its products at any time without notice.
revision history 3 preliminary information AMD-8131? hypertransport? pci-x tunnel revision guide 26310 rev. 3.02 july 2003 revision history date revision description july 2003 3.02 added erratum #52?53. changed errata #48 fix planned status to ?no?. april 2003 3.00 initial public release.
4 revision history preliminary information 26310 rev. 3.02 july 2003 AMD-8131? hypertransport? pci-x tunnel revision guide
5 26310 rev. 3.02 july 2003 preliminary information AMD-8131? hypertransport? pci-x tunnel revision guide AMD-8131 tm hypertransport tm pci-x tunnel revision guide the purpose of the AMD-8131? hypertransport? pci-x tunnel revision guide is to communicate updated product inform ation on the AMD-8131? hypertransport? pci-x tunnel to designers of computer systems and software devel opers. this guide consists of three major sections: revision determination: this section, which starts on page 6, describes the mechanism by which the current revision of the part is identified. product errata: this section, which starts on page 7, prov ides a detailed description of product errata, including potential effect s on system operation and suggested workarounds. an erratum is defined as a deviation from produc t specifications, and as such may cause the behavior of the AMD-8131 hypertransport pci-x tunnel to devi ate from the published specifications. documentation support: this section, which starts on page 21, provides a listing of available technical support resources. revision guide policy occasionally, amd identifies product errata th at cause the AMD-8131 hype rtransport pci-x tunnel to deviate from published specificat ions. descriptions of identified product errata are designed to assist system and software designers in using the AMD-8131 hypertransport pci-x tunnel. furthermore, this revision guide may be updated periodically.
6 revision determination preliminary information 26310 rev. 3.02 july 2003 AMD-8131? hypertransport? pci-x tunnel revision guide revision determination the bios checks the pci revision id register at deva:0x08 to determine the version of silicon as shown in table 1. table 1. AMD-8131 hypertransport pci-x tunnel revision ids sequence revision dev[b, a]:0x08 3b1 12h
product errata 7 preliminary information AMD-8131? hypertransport? pci-x tunnel revision guide 26310 rev. 3.02 july 2003 product errata this section documents AMD-8131 hypertransport pci-x tunnel product errata. a unique tracking number for each erratum has been assigned within th is document for user convenience in tracking the errata within specific revision levels. table 2 cro ss-references the revisions of the part to each erratum. an ?x? indicates that the erratum applies to the revisi on. the absence of an ?x? indicates that the erratum does not apply to the revision. note: there may be missing errata numbe rs. errata that have been resolved from early revisions of the device have been deleted, and errata that have been reconsidered may have been deleted or renumbered. table 2. cross-reference of pr oduct revision to errata errata numbers and description revision number b1 29 error in fairness algorithm x 37 potential pci-x mode starvation scenario x 43 pci-x secondary clock frequency register not updated properly x 44 potential hang associated with pci disconnect without data x 45 secondary bus reset to a non-hot plug bridge x 46 parity checking gap on peer-to-peer i/o writes x 47 issues with the pci-x relaxed ordering bit in i/o transactions x 48 link electrical issue when operating at 800 mhz x 49 failure to comple te 4 kbyte transfer x 50 serr# enable does not inhibit crc sync floods x 51 stale data scenario with pci prefetching x 52 posted write starvation scenario x 53 non-compliant error indication from special cycles x
8 product errata preliminary information 26310 rev. 3.02 july 2003 AMD-8131? hypertransport? pci-x tunnel revision guide 29 error in fairness algorithm description the pci-x tunnel does not correctly implement the fairness algorithm specified by the hypertransport i/o link specification. in situations in which a virtual channel (vc) to the host is clogged with more transaction bandwidth than can be supported by the system, the pci-x tunnel allocates bandwidth as follows?roug hly 50% is allocated to inserted traffic from the pci bridges and roughly 50% is allocated to forwarded traffic from the other side of the tunnel. potential effect on system normally, bandwidth to a clogged vc should be allocated fairly between all devices in a hypertransport chain. for example, the inserted bandw idth in a four-device chain would be allocated as follows: host ---- device 0 ---- device 1 ---- device 2 ---- device 3 25% 25% 25% 25% as a result of this erratum, inserted bandwidth to a clogged vc is allocated as follows, based on the number of pci-x tunnel devices in the hypertransport chain: host ---- device 0 ---- device 1 50% 50% host ---- device 0 ---- device 1 ---- device 2 50% 25% 25% host ---- device 0 ---- device 1 ---- device 2 ---- device 3 50% 25% 12.5% 12.5% note that this erratum only affects chains of three or more pci-x tunnel devices. suggested workaround for systems that require three or more pci-x tunnel devices in a chain, it is recommended that the devices supporting the lowest-bandwidth pci br idges be placed furthest from the host. fix planned no
product errata 9 preliminary information AMD-8131? hypertransport? pci-x tunnel revision guide 26310 rev. 3.02 july 2003 37 potential pci-x mode starvation scenario description the pci-x bridge arbite r uses a round robin protocol for sel ecting between external masters and internal requests. if all eight non-posted request buff ers are consumed by external masters, then the following starvation scenario is possible: 1. the pci-x tunnel is granted the bus by the arbite r for a split completion to the pci-x bus for an outstanding non-posted request. as a result of this split completio n, there are seven outstanding non-posted requests. 2. the arbiter grants the bus to a first master. this master generates a non-pos ted request. as a result, all eight non-posted request buffers of the bridge are occupied. 3. the arbiter grants the bus to a second mast er. this master generates a non-posted request. however, since all non-posted request buffers of the bridge are occupied, this request is retried by the pci-x tunnel. this sequence can repeat indefinitely. potential effect on system pci-x bus bandwidth may be grante d to external masters unevenly. suggested workaround system bios should program the maximum outstanding split transactions field of the pci-x command register (per the pci-x 1.0 sp ecification) in external masters as follows, such that a master cannot be starved: fix planned no table 3. maximum outstanding split transactions number of masters 1st master 2nd master 3rd master 4th master 18 244 3233 4 2 222
10 product errata preliminary information 26310 rev. 3.02 july 2003 AMD-8131? hypertransport? pci-x tunnel revision guide 43 pci-x secondary clock frequency register not updated properly description after a hot plug speed/mode change command (s hpc[b, a]:14[cmd]) to change the speed or mode of the pci bus, the pci-x capability registers dev[b, a]: 0xa0[scf] and dev[b, a]:0x40[cpci66] should be updated to reflect the new speed or mode of the pci bus. however, they remain in their default state for hot plug m ode, indicating a 33?mhz conventional pci bus. potential effect on system none. suggested workaround none. fix planned no
product errata 11 preliminary information AMD-8131? hypertransport? pci-x tunnel revision guide 26310 rev. 3.02 july 2003 44 potential hang associated wi th pci disconnect without data description when there is a host access to a secondary-b us pci device under the following conditions: the bridge is in conventional pci mode. the target pci device responds as a 32-bit device (ack64# is not asserted). the access starts at or passes through the low doubleword of a naturally-aligned quadword (address bit 2 low) and cont inues to at least the next naturally- aligned quadword. thus, it covers at least three doublewords. the target pci device always disconnects after no more than one (32-bit) data phase (in which irdy# and trdy# are asserted). the target pci device always disconnects wit hout data (stop# asserted, trdy# deasserted). then the following hang scenario is possible: 1. the first address phase is followed by the firs t data phase of the transac tion, during which the low doubleword of a naturally-aligned qu adword is properly transferred. 2. the pci target disconnects without data. 3. the pci-x tunnel reinitiates the transaction with the same address as the first address phase (address bit 2 low) with no vali d byte enables in the low d oubleword (be#[3:0]=1111b), even though it should have started at the ne xt doubleword address (address bit 2 high). 4. the pci target enables the transfer of a single doubleword of data corresponding to the low doubleword of the address with no valid byte enables. 5. the pci target disconnects without data. 6. steps 3, 4, and 5, are then repeated inde finitely, resulting in the hang condition. potential effect on system the system hangs. suggested workaround device drivers for pci devices that exhibit the de scribed behavior should be written such that accesses to device registers are limited to no more than 8 bytes per request. fix planned no
12 product errata preliminary information 26310 rev. 3.02 july 2003 AMD-8131? hypertransport? pci-x tunnel revision guide 45 secondary bus reset to a non-hot plug bridge description when (1) the pci-x tunnel is configured such that one bridge is in hot plug mode and the other bridge is not in hot plug mode and (2) the secondary bus reset configuration bit, dev[b, a]:0x3c[sbrst], is set in the bridge that is not in hot plug mode, then clearing this bit causes the shpc hot plug controller for the other bridge to hang. potential effect on system subsequent commands to the hot plug controller are not executed. hot plug events such as changing pci cards are not possible. suggested workaround do not support configurations in wh ich one bridge is in hot plug mode and the other bridge is not in hot plug mode. if this configuration is required, then do not support software that sets (and then clears) dev[b, a]:0x3c[sbrst]. fix planned no
product errata 13 preliminary information AMD-8131? hypertransport? pci-x tunnel revision guide 26310 rev. 3.02 july 2003 46 parity checking gap on peer-to-peer i/o writes description when a pci device operating in conventional pci mode generates an i/o write transaction as a master, then the following sequence of events occurs: 1. the i/o write transaction is claimed by the pci-x tunnel. 2. when irdy# from the pci device is asserted, the data associated with th e i/o write is captured by the pci-x tunnel and passed into the corresponding hypertransport packet. 3. the pci transaction is retried (disconnected wi thout a trdy# assertion from the pci-x tunnel). 4. the pci device retries the i/o write until the pci-x tunnel has received the tgtdone hypertransport packet associated with the i/o writ e, at which point the transaction is completed with the simultaneous assertion irdy# and trdy#. however, the pci-x tunnel only checks data pari ty when irdy# and trdy# are both asserted. if there is a transient parity error on the initial transaction in which the data is captured by the pci-x tunnel, then the error will not be detected. potential effect on system erroneous data is passed from a pci de vice to another device in the system. suggested workaround do not populate the system wi th devices that generate peer-to-peer i/o writes. fix planned no
14 product errata preliminary information 26310 rev. 3.02 july 2003 AMD-8131? hypertransport? pci-x tunnel revision guide 47 issues with the pci-x relaxed ordering bit in i/o transactions description according to the pci-x specification, the relaxed ordering attribute bit s hould not be set in i/o requests or completions to i/o requests. howe ver, if the pci-x tunnel receives an i/o-space hypertransport read request with the rsppasspw bi t set (bit 3 of the rdsized command), then the relaxed ordering attribute bit of the corresponding pci-x tr ansaction is set. note: there are no known hosts that ge nerate i/o-space requests in wh ich the rsppasspw bit is set. also, if (1) a pci-x master gene rates a peer-to-peer i/o request that passes through a hypertransport link and (2) the passpw bit of the corresponding hypertransport response is set, then the pci-x tunnel sets the relaxed ordering at tribute bit in the corresponding pc i-x completion. even though it is a violation of pci-x protocol to set the relaxed ordering attribute bit in the completion to an i/o request, it is not a violation of h ypertransport protocol for a target to set passpw in the response to an i/o request. therefore, the pci-x tunnel should clear the relaxed ordering attribute bit in all completions to i/o requests, regardless of the state of passpw in the response. potential effect on system the pci-x protocol violation may result in undefined behavior of pci-x devices. suggested workaround do not support hosts that generate i/o-space hypertransport read requests with the rsppasspw bit set and do not populate the system with pci-x de vices that generate peer-to-peer i/o cycles. fix planned no
product errata 15 preliminary information AMD-8131? hypertransport? pci-x tunnel revision guide 26310 rev. 3.02 july 2003 48 link electrical issue wh en operating at 800 mhz description the pci-x tunnel links do not operate properly at 800 mhz. potential effect on system transfer of erroneous data and system deadlocks are possible. suggested workaround the links should be configured to op erate at 600 mhz instead of 800 mhz. fix planned no
16 product errata preliminary information 26310 rev. 3.02 july 2003 AMD-8131? hypertransport? pci-x tunnel revision guide 49 failure to complete 4 kbyte transfer description if a transaction with the following characteristics occurs, then the pci-x tunnel may fail to transfer the last several bytes of the request: a pci-x master generates a memo ry read request for 4096 bytes. the transaction starting address is not quadword aligned (a[2:0] not 000b). nearly all of the completion data is conti nuously bursted onto the pci-x bus without any disconnects. potential effect on system the system may hang. suggested workaround system bios should set the maximum memory read byte count field of the pci-x command register (in the pci-x type 0 cap abilities register set) in all secondary-bus pci-x devices to no greater than 2 kbytes. fix planned no
product errata 17 preliminary information AMD-8131? hypertransport? pci-x tunnel revision guide 26310 rev. 3.02 july 2003 50 serr# enable does not inhibit crc sync floods description if dev[b, a]:0x04[serren] is clear, then no dete cted errors should result in sync floods on hypertransport links. however, if deva:0x[c8 or c4][crcfen] is set and a crc error is detected on the corresponding link, then the pci-x tunnel will generate a sync flood. potential effect on system unexpected sync floods occur. suggested workaround if it is desired that crc errors do not ca use sync floods, then system bios should leave deva:0x[c8 and c4][crcfen] clear. fix planned no
18 product errata preliminary information 26310 rev. 3.02 july 2003 AMD-8131? hypertransport? pci-x tunnel revision guide 51 stale data scenario with pci prefetching description if the following sequence occurs, then stal e data may be delivered to a pci master: 1. a conventional pci master initia tes transaction a to cacheline n. 2. the pci-x tunnel prefetch es cachelines n, n+1, etc. 3. the response data for transaction a is burst onto th e pci bus, but it is disconnected at the end of cacheline n. 4. there is an intervening host transaction to the bridge (possibly to indicate th at new data is valid to the master in question). 5. the master initiates transact ion b to cacheline n again. then, when the pci-x tunnel reaches cacheline n+ 1 on the pci bus for transaction b, it should discard the data prefetched at cacheline n+1 for tran saction a and request the data again. however, it does not do so. it allows the prefetched data as sociated with transacti on a to be supplied for transaction b. potential effect on system incorrect data may be supplied to the pci master. suggested workaround system bios should set dev[b, a]:0x4c[dpdh]. fix planned no
product errata 19 preliminary information AMD-8131? hypertransport? pci-x tunnel revision guide 26310 rev. 3.02 july 2003 52 posted write starvation scenario description consider a system which includes the AMD-8131 pc i-x tunnel connected to an upstream device (on the a-side link) and a do wnstream device (on the b- side link). if (1) a cont inuous stream of response packets are passing downstream through the pci-x t unnel, (2) these response packets are allowed to pass posted writes (i.e., the passpw bit is set in a ll of them), (3) there are always response buffers reported to be available in the downstream device, and (4) a posted write is also sent downstream through the tunnel, then the posted write stalls in the pci-x tunnel. this posted write will not make forward progress until either there are no more r esponse packets to forward downstream or the downstream device runs out of response buffers. note that subsequent downstream posted writes will stall behind this posted wr ite. this scenario may ultimately stall the host from executing instru ctions if it genera tes enough posted writes. potential effect on system the processor may stall for long pe riods of time, or inde finitely, while it is waiting for the posted channel to clear. this may result in reduced pr ocessor performance or in the expiration of watchdog timers in the system. suggested workaround no workaround is expected to be required. the c onditions necessary to creat e this scenario are not expected to occur with real world applications. fix planned no
20 product errata preliminary information 26310 rev. 3.02 july 2003 AMD-8131? hypertransport? pci-x tunnel revision guide 53 non-compliant error indi cation from special cycles description the upstream response to special cycles that target the pci bus (initiated by downstream configuration-space writes to off set 0, function 7, device 31 of the secondary bus number) should never indicate a target-abort error. however, if dev[b, a]:0x3c[marsp] is set, then the response packet to the special cycle request indicates a target-abort error (the er ror bit is set and the nxa bit is clear). potential effect on system system software may erroneously record that a target-abort error occured. suggested workaround none expected to be required. th ere is no known operational software that generates pci-bus special cycles. if pci-bus special cycles are required to be supported, then dev[b, a]:0x3c[marsp] may be cleared to avoid the problem. fix planned no
documentation support 21 preliminary information AMD-8131? hypertransport? pci-x tunnel revision guide 26310 rev. 3.02 july 2003 documentation support the following documents provide additional information regarding the operation of the AMD-8131 hypertrans port pci-x tunnel: AMD-8131? hypertransport? pci-x tunnel data sheet , order# 24637. hypertransport? i/o link specification (www.hypertransport.org). see the amd web site at www.amd.com for the latest updates to documents. for documents subject to a non-disclosure agreement, please contact your local sales representative.
22 documentation support preliminary information 26310 rev. 3.02 july 2003 AMD-8131? hypertransport? pci-x tunnel revision guide

▲Up To Search▲

Price & Availability of AMD-8131

	To Download AMD-8131 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .